Re: Moving from 32 to 64 bit builds on Solaris

At 7:47 PM +0100 3/10/07, Martijn van Oosterhout wrote:
>On Sat, Mar 10, 2007 at 08:30:20AM -0500, Dan Sugalski wrote:
>>  Possibly it won't. The machine the DB is on sees heavy access to
>>  large files, to the point where parts of the database may get flushed
>>  out of the OS buffer cache. I was working on the (possibly deeply
>>  flawed assumption) that I'd be better off if more of the database was
>>  guaranteed pinned in memory in Postgres' buffer cache -- it wouldn't
>
>Err, is shared memory actually guarenteed to be pinned in memory? I
>mean, in Linux it's not as that is a form of DOS attack, pin all memory
>by allocating it as SHM.

I'm not worried about swapping -- the box has more than enough memory
that it's not going to swap.

What I am looking at is response times after a relatively long (20-30
minute) period of inactivity. When the database is being accessed and
the data files are either in shared buffers or OS file cache,
performance is really snappy. When the database has been ignored for
a while and other things go on the box, postgres' data files get
expunged from the OS caches, and access times for the first few
queries go from milliseconds to seconds. No surprise, certainly, HD
access times being what they are.

I've  got enough memory on the box that I can reasonably map a four
or five gig into postgres and just leave it there. It'll probably not
slow down anything else significantly, but if it means the difference
between having to re-read a page from disk and just hit shared
buffers, then it's worth it in response time.
--
                Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk